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Procede et dispositif de contrdle d'un trafic de paquets de donnees en entree 
d'un reseau, programme d'ordinateur et equipement reseau correspondants. 

Le domaine de l'invention est celui des reseaux de communication, et 
notamment mais non exclusivement des reseaux de type IP ou equivalents. 

Plus precisement, l'invention concerne un procede de contrdle d'un trafic de 
paquets de donnees en entree d'un reseau, dans le cas ou le trafic comprend une pluralite 
de flux et/ou sous-flux associ6s chacun a un niveau de priority et ou chacun des paquets 
est marque avec le niveau de priorite associ£ au flux ou sous-flux auquel appartient ce 
paquet En d'autres termes, l'invention concerne un m6canisme reseau permettant 
d'optimiser l'ecoulement d'un trafic entrant sur un reseau. 

L'invention a de nombreuses applications, telles que par exemple le controle de 
flux multimedia (par exemple des flux MPEG), seuls ou par agregats, ou encore ,le 
controle d'un multiplex de flux de differentes natures (par exemple un flux video/audio 
multiplex^ avec un flux TCP, sur un acces ADSL). • 

On presente maintenant briSvement le contexte r6seau dans lequel se situe ?k 
presente invention. 

L'aiigmentation des performances des ordinateurs ainsi que les debits offerts par 
Jes nouvelles generations de reseaux ouvrent la voie a de nouveaux services bases sur les 
flux multimedias. De fait, le nombre d' informations audiovisuelles transmises sur les 
reseaux (par exemple de type IP (« Internet Protocol »)) croit sans cesse, et les 
algorithmes de compression (par exemple de type MPEG (« Moving Picture Experts 
Group »)) s'am61iorent, offrant une qualite meilleure avec des debits plus faibles. 
Cependant, aujourd'hui ie niveau de qualite n'est pas toujours acceptable. Si chaque 
maillon de la chaine a les capacit^s intrinsSques pour fournir cette qualite, leur mise bout 
£ bout et le partage des ressources r6seau IP par de nombreux usagers aboutissent parfois 
k des resultats mediocres. 

D'une maniere generale, la transmission d'informations dans un reseau IP 
s'appuie sur la couche transport pour un controle de la qualite entre la source et Jes 
recepteurs. Cette couche, situee entre le routage et les applications, est r6alisee 
traditionnellement par le protocoleTCP (« Transmission Control Protocol »). D'un point 
de vue application, TCP se charge de retransmettre les informations perdues ou mal 



re§ues, par un controle au niveau de la session. D'un point de vue reseau, certains 
parametres du protocole permettent de deceler des possibles congestions, et d' adapter le 
debit de la source aux contraintes du r6seau. L'objectif est alors de limiter le d<§bit si le 
reseau ne peut pas tout ecouler, et d'eviter d'envoyer des paquets qui seront perdus. De 
nombreuses etudes cherchent aujourd'hui h appliquer des mecanismes equivalents aux 
flux video, avec la contrainte temps r6el d'une adaptation dynamique des codeurs au 
debit disponible. 

Mais en raison du temps important de reaction entre un ou plusieurs clients et la 
source video, les protocoles temps reel et audiovisuels ne font actuellement que peu de 
traitements, et se limitent principalement au marquage du temps Remission et & 
l'encapsulation des paquets de Implication pour leur routage dans la couche IP (par 
exemple RTP/UDP), a charge des applications de se debrouiller avec les donnees re9ues. 

devolution des reseaux offre la possibilite de g6rer la « qualite de service » 
(QoS) dans les routeurs. Or, il est pertinent de remarquer que c'est le lieu ou se 
produisent la plupart des pertes des reseaux IP, et des m6canismes sont mis en oeuvre & 
ce niveau pour traiter selectivement les differents flux en vue d' assurer au mieux des 
objectifs de qualite. Les moyens dgployes pour ameliorer la qualite des flux transmis 
sont V objet des travaux des groupes « IntServ » (pour « integrated services », c'est-^-dire 
« integration de services ») et « DiffServ » (pour « differentiated services », c'est-fc-dire 
« services diff6renci6s ») a 1 ! IETF (Internet Ingineering Task Force) : 

- « IntServ » definit des moyens pour reserver une ressource en debit garantie 
entre deux noeuds d'un reseau ; 

- « DiffServ » definit des moyens pour contrSler dynamiquement le d6bit 
d'agr6gats de flux en fonction de la charge du r6seau. 

En comparaison avec les solutions de bout en bout (analogues a TCP) les 
solutions localisees dans les routeurs ont plusieurs avantages : 

- elles s'affranchissent de toute contrainte de session ; 

- elles sont aussi adapt6es au temps reel, car leur action dans les routeurs est 
immediate sans necessiter de retour d' informations en provenance des 
usagers ; 
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- elles sont done naturellement adaptees a la diffusion selective (« multicast »), 
car independantes du nombre d'usagers alimentis par le flux et 
independantes de rapports en provenance d'un nombre variable d'usagers. 

Les traitements dans les routeurs s'appuient sur une distinction des paquets 
arrivant dans les routeurs supportant des mecanismes de « quality de service » (QoS, 
pour « Quality of Service »). 

Cette distinction existe naturellement dans les flux MPEG, car la compression 
des flux video MPEG aboutit a une suite de donnees de natures differentes et non 
independantes. On distingue trois types d'images : I, P et B. Les images de type I antra), 
sont chacune codees sans faire reference a une autre image, la compression etant Iimitee 
a la reduction des redondances spatiales au sein de chaque image. Pour optimiser la 
quantity d'informations transmises, les codeurs MPEG exploitent le fait que deux 
images consecutives sont peu differentes en general. Une detection de mouvement ne 
considere que la partie qui vient de changer par rapport a l'image precedente pour 
obtenir une information de taille requite codee dans une image de type P (Predite^. 
D'autres moyens permettent d'obtenir une information encore plus reduite en interpolaht 
les mouvements entre deux images de type IouP; ces images sont alors de type B 
(Bidirectionnelle). 

La taille des images P est beaucoup plus petite en general que celle des images I, 
et un codage avec peu d'images I permet d'obtenir, a debit equivalent, une qualite de 
d6codage bien superieure. Dans ces conditions, la perte d'une image n'est pas 
equivalente en fonction de la nature de reformation qu'elle contient. Cette structure de 
1'information doit conduire a consider 1'importance ou le poids de chaque information 
dans son traitement par le reseau. 

Deux raisons justifient la conservation d'images I : 

- la re-synchronisation periodique du flux en cas de pertes ; 

- tout changement de scene car il n'est plus possible de s'appuyer sur les 
images prec6dentes pour un codage de mouvement. 

Une autre maniere de considerer ce poids de 1'information est la decoupe d'un 
flux MPEG4 en plusieurs niveaux hierarchiques pour obtenir une qualite variable en 
fonction du contenu global recu par l'usager. Un niveau hieVarchique N doit s'appuyer 
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sur la presence des N-l niveaux inferieurs pour apporter un complement de qualite. Un 
cas 616mentaire est de consid6rer une video constitute d'un flux de base (contenant des 
images I et P) et d'un flux de rehaussement (contenant des images P et B). Pour ce cas 
(Slementaire, le flux de base dans sa globalit6 est considere plus prioritaire que le flux de 
rehaussement. 

La distinction de nature des images ou des flux dans le trafic MPEG est & 
exploiter dans les routeurs « DiffServ » pour traiter selectivement les differentes 
informations d'un flux video : 

- soit par un marquage du champs TOS (« type of service », c'est-a-dire « type 
de service ») ou DSCP (« Differentiated Services Code Point », c'est-a-dire 
« valeur de marquage pour services diff6rencies ») des paquets par le serveur 
video, 

- soit par une classification effectuee par le routeur, ce qui aboutit egalement a 
un marquage des paquets IP. 

Dans le present document, on considere que le marquage des paquets est 
possible dans tous les cas. Les moyens de r6aliser ce marquage sont consideres comme 
bien connus de l'homme du metier. lis ne sont done pas discutes en detail. 

Quand une situation de congestion apparait dans un routeur, les paquets re?us 
sont 61imines en fonction de la charge et de leur niveau de priorit6. 

Une caracteristique importante des donn6es contenus dans ces paquets est leur 
variation importante en fonction du contenu de la scene. Or, les informations les plus 
critiques pour la restitution k Tusager sont contenues dans les rafales les plus 
importantes, et le probleme principal des r6seaux IP de type « Best effort » (c'est-a-dire 
sans garantie) est leur difficulte & laisser passer les rafales en cas de congestion. 

De ce fait, le simple marquage des flux 616mentaires d'un flux MPEG n'est pas 
suffisant pour leur traitement optimal. En effet, les mecanismes « DiffServ » usuels sont 
prevus pour accepter des rafales que Ton trouve habituellement dans les reseaux IP, avec 
les applications qui sont majoritaires aujourd'hui : le transfert d'URL (« Uniform 
Resource Locator ») pour les applications WEB et les transferts de fichiers par FTP 
(« File Transport Protocol »). Toutes ces applications exploitent le protocole TCP dont 
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les mecanismes ont fait l'objet de nombreuses etudes afin d'obtenir une montee en 
charge progressive, et une adaptation du d6bit en fonction de la charge du reseau. 

Or, les flux video remettent en cause ce fonctionnement car leur comportement 
est qualifie d'agressif, dans la mesure ou ils ignorent generalement l'etat et la charge du 
5 reseau. De plus, la plupart des m6canismes introduits dans les reseaux IP ont tous pour 

objectif le lissage des flux pour favoriser un bon ecoulement du trafic. Paradoxalement, 
les codeurs fournissent une qualite" meilleure quand ils produisent des flux a debit 
variable, qui sont les plus maltraites dans les reseaux IP. 

L' introduction de flux video dans le reseau IP se heurte done a trois 
10 contradictions : 

- augmenter la qualite des codages, conduit pour un debit moyen defini, a 
produire des rafales de paquets quand la sequence codee 1'exige ; 

- les reseaux d'acces offrent une bande passante maximale limitee (y compris 
en ADSL (« Asymetric Digital Subscriber Line ») car les applications sont 
tentees d'exploiter un debit moyen proche du maximum pour procurer 4a. 
meilleure quality aux usagers ; 

- les rafales sont les informations les plus importantes car elles correspondent a 
un changement de scene ou au moins a un changement important du contenu 
de 1' image. Bien souvent, ces images sont du type I antra) dont la perte est 
tres critique, car il devient impossible de reproduire les images suivantes, 
mSme si ces derni&res sont correctement regues. 

On pr6sente maintenant les techniques connues de conditionnement de trafic 
visant a reduire les congestions dans les reseaux. 

On notera tout d'abord que les travaux sur Implication de la mise en forme pour 
les flux MPEG dans les reseaux IP en se basant sur UDP et RTP comme protocols de 
transport sont tres rares. La majorite des travaux concernent les reseaux ATM 
(« Asynchronous Transfer Mode ») et I'utilisation de TCP comme protocole de 
transport. 

Les mecanismes de mise en forme et de conditionnement de trafic sont utilised 
dans les reseaux IP a « qualit6 de service » (QoS). On peut notamment se reporter au 
document « Traffic Shaping for MPEG video transmission over next generation 
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internet » (lissage de trafic pour la transmission de video MPEG sur T internet de 
prochaine generation), M.F Alan, M. Atiquzzaman, M.A. Karim. Dans ce document, le 
lissage de trafic (TS) est utilise pour assurer la conformite des flux MPEG au TSPEC 
(« Traffic Specifier » c'est-^-dire « specification de trafic ») necessaire a la reservation 
de ressources dans les reseaux « IntServ ». Pour les reseaux « DiffServ », le traitement 
se fait par agregat de flux et done sans trop se soucier des applications. Les algorithmes 
de lissage de trafic (TS) sont par contre largement utilises au niveau du codage dans le 
but de contr61er le debit des codeurs. Ceci reste insuffisant pour maitriser les flux au 
niveau reseau. 

L'utilisation de la mise en forme, par lissage de trafic (TS, pour « Traffic 
Shaping ») ou controle des regies de trafic (ou TP, pour « Traffic Policing »), pour 
reduire la congestion dans le reseau peut ameliorer d'une maniere significative le niveau 
de « qualite de service » (QoS) que le reseau est capable de delivrer aux applications. 

Le lissage (TS) lisse les rafales en « bufferisant » (e'est-k-dire en mettant en 
memoire-tampon) les paquets concernes par Texces de rafales dans les equipements de 
frontiere du reseau. II peut reduire la congestion a des niveaux acceptables, surtout que 
les algorithmes d'ordonnancement (« scheduler ») tels que CBQ (« Class Based 
Queuing » c'est-&-dire « gestion de files d'attente basees par classes de services ») ou 
bien PQ (« Priority Queuing » e'est-a-dire « gestion de files d'attentes par priori tes ») ne 
sont pas capables de le faire. Utilises seuls, ces mecanismes propagent les rafales dans le 
reseau. 

Comme le lissage (TS), le controle des regies de trafic (TP) limite le debit du 
trafic au d6bit configure. Mais au lieu de « bufferiser » les paquets comme le lissage 
(TS), les paquets non-conformes sont soit rejet6s, soit remarques pour diminuer leurs 
priorit6s. Le controle des regies de trafic (TP) ne lisse pas par consequent le trafic mais 
il n'introduit pas de delai de « bufferisation » non plus. 

Dans la majorite des architectures qui supportent la « qualite de service » (QoS), 
un contrat de service existe entre le fournisseur du service reseau (NSP, pour « Network 
Service Provider ») et le fournisseur de l'application (ASP, pour « Application Service 
Provider »). Dans les reseaux ATM, ce contrat est appele « Contrat de trafic ». Dans les 
reseaux « DiffServ », les aspects de contractualisation sont trails dans le SLA 



(« Service Level Agreement ») et plus precisement dans le SLS (« Service Level 
Specification »). 

On connait 6galement le document suivant : RFC2475, « An Architecture for 
Differentiated Services » (une architecture pour des services differencies), Decembre 
1998. II precise que les sources de trafic peuvent assurer Ies taches de classification et de. 
conditionnement de trafic. En effet, le trafic peut etre marque - avant de quitter le 
domaine source. Ce marquage initial est appel6 « Initial Marking » ou « Pre-marking ». 
L'avantage du marquage initial est que les preferences et les besoins des applications 
peuvent etre mieux pris en compte pour decider quels paquets doivent recevoir un 
meilleur traitement dans le reseau. 

La pr6vention contre la surcharge d'une classe de service donnee n'est pas une 
tSche facile dans les reseaux « DiffServ ». En plus, en cas de surcharge dans une classe 
de service, il faut noter que tous les flux de cette classe de service souffrent d'utfe 
degradation de la « qualite de service » (QoS). 

En plus, plusieurs mecanismes utilises dans la mise en oeuvre de « DiffServ'» 
fonctionnent d'une facon moins efficace en presence des rafales. Le mdcanisme RED 
(« Random Early Drop »), par exemple, est plus efficace lorsqu'il est applique a uh 
trafic lisse\ sinon ce sont les flux lisses qui sont penalises alors que les flux en rafales he 
subissent pas une amelioration significative. 

Les flux MPEG sont caracteris6s par le fait qu'ils prSsentent des rafales (nature 
« bursty ») et par leur sensibility aux pertes de paquets. Ces pertes causent une 
degradation de la quality subjective, mais il est tres difficile de prevoir le niveau de cette 
degradation suite a des pertes. Cette degradation est fortement liee a la nature des 
informations transporters par les paquets perdus. Les mecanismes de correction 
d'erreurs sont utilises lors du decodage pour palier aux pertes. 

Gerer les flux MPEG dans le reseau, ou m8me dans les routeurs d'extremite" (ER, 
pour «Edge Router »), est une tache compliquee. Le fournisseur du service reseau 
(NSP) n'est pas oblige" de trailer differemment les flux MPEG. En plus, l'agregat de 
trafic resultant de plusieurs flux audio-visuels est generalement difficile a decrire : 

- le processus d'arrivee de paquets est auto-similaire ; 

- grande variation des donnees transport^es par les paquets ; 



— la dynamique des protocoles. 

Une solution consiste h marquer les paquets et a leur attribuer le niveau de 
« qualite de service » (QoS) approprte avant qu'ils quittent le domaine du fournisseur de 
service sur Internet (ISP, pour « Internet Service Provider »). La passerelle d'acces au 
media (MAG, pour « Media Access Gateway ») est par exemple responsable de cette 
tache. Cette passerelle MAG gere le trafic selon le SLS specifie. Cette approche facilite 
la negociation de SLA/SLS pour les services en mode continu (« Streaming ») et impose 
au client un profil de trafic bien particulier. 

Parmi les techniques actuelles, la plus nSpandue pour controler le trafic est le 
mecanisme WRED (« Weighted Random Early Drop ») qui consiste en une perte de 
paquets aleatoire et differente en fonction du marquage des paquets. Ce mdcanisme se 
base sur un taux de remplissage moyen de la file d'attente d' emission sur un lien d'un 
reseau. Mais cette technique introduit un caractere aleatoire des rejets de paquets, et le 
taux de remplissage de la file d'attente n'est pas optimisee. Selon les tailles des rafales et 
leur frequence, ces rejets peuvent se produire pour un remplissage faible ou un 
remplissage tres el eve de la file d'attente. Ce qui conduit d'une part a une sous 
utilisation de la file d'attente, et d'autre part a la reservation de taille m£moire 
cons6quente pour la realisation de cette file. Ce probleme existe pour tout type 
d' application, et il est encore plus r6el pour les flux audiovisuels en raison de leurs 
rafales importantes. 

Pour detailler ce point, il est fondamental de remarquer tout d'abord que les 
rafales des flux vid6o sont impr6visibles, autant en taille qu'en duree, tout en 
garantissant un debit moyen sur une p6riode de 1'ordre d'une seconde. Cette fenetre de 
calcul du debit moyen est beaucoup trop grande pour obtenir des tailles raisonnables des 
files d'attente associ6es. De fait, les routeurs reagissent en calculant les moyennes de 
remplissage sur une dizaine de paquets regus, alors que certaines rafales peuvent 
largement depasser les 20 paquets. 

Ainsi, une succession de rafales peut aboutir k des rejets par saturation de la 
capacit6 de la file d'attente, inhibant le fonctionnement normal du mecanisme. A 
l'oppose, quand un trafic faible survient apres une suite de rafales, la valeur moyenne 



peut rester temporairement anormalement elevee et des paquets sont rejetes alors que la 
file est pratiquement vide. 

Le mecanisme WRED n'est done pas adapte" au contr61e de flux caracterises par 
une valeur moyenne sur une duree fixe. 

L'invention a notamment pour objectif de pallier ces inconvenients de I'etat de la 
technique et offrir une solution optimale en cas de congestion du reseau. 

Plus precisement, l'un des objectifs de la presente invention est de fournir un 
precede et un dispositif de controle de trafic permettant de controler des rafales et de 
lisser le trafic sur un ensemble de flux et/ou sous-flux associes a des niveaux de 
priorites. 

En d'autres termes, un objectif de la presente invention est de fournir un proc6de 
et un dispositif de controle de trafic permettant de proteger les informations importantes 
des rafales, afin d'apporter une solution a 1'antinomie entre 1'optimisation d'un flux (par 
exemple un flux video) contenant des rafales et le lissage des rafales pour un transport 
de qualite dans le reseau. 

L'invention a egalement pour objectif de fournir de tels procede et dispositif qtii 
soient simples a mettre en oeuvre et peu coQteux. 

Un autre objectif de l'invention est de fournir de tels procede" et dispositif 
permettant de proposer efficacement des contrats de trafic (SLA/SLS) entre operateurs 
reseau et fournisseurs de services. 

Ces differents objectifs, ainsi que d'autres qui apparattront par la suite, sont 
atteints selon l'invention a l'aide d'un procede de controle d'un trafic de paquets de 
donnees en entree d'un nSseau, le trafic comprenant N flux et/ou sous-flux associes 
chacun a un niveau de priority N > 2, chacun des paquets 6tant marque avec le niveau 
de priority associe" au flux ou sous-flux auquel appartient ledit paquet, 
ledit proc&te comprenant une etape de mise en ceuvre d'un mecanisme de seau a jetons a 
N niveaux de fonctionnement avec N memoires-tampons de jetons contenant chacune un 
nombre de jetons disponibles, les jetons de chacune des N memoiresTtampons de jetons 
6tant utilises pour traiter l'un des N niveaux de priorite, chacun des paquets etant 
accept ou refuse selon qu'il est possible ou non de lui attribuer des jetons en fonction 
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des jetons disponibles au moins dans la memoire-tampon de jetons utilisee pour traiter le 
niveau de priorite dudit paquet. 

Le principe general de l'invention consiste done k utiliser un seau a jetons multi- 
niveau (MLTB, pour « Multi Layer Token Bucket ») pour rejeter les paquets en dehors 
d'un profil requis et caracterise par les N niveaux de fonctionnement du seau a jetons 
multi-niveau. Chaque paquet subit un traitement selon un marquage correspondant & son 
niveau de priorite. Les paquets acceptes sont places dans une file d'attente. 

Le seau a jetons multi-niveau permet de traiter s61ectivement et conjointement 
plusieurs niveaux de priorites de flux. II est bien adapts k la caracterisation du trafic 
entre la taille des rafales en entr6e et 1'ecoulement du trafic en sortie. On sait qu'en cas 
de congestion du reseau, il est illusoire de chercher de la bande passante disponible. Le 
reglage des parametres du seau & jetons multi-niveau assure une relation entre les 
niveaux de priorite pour <5quilibrer les contraintes de fonctionnement entre les debits par 
niveaux de priorite et les rafales acceptables par le seau & jeton selon les contraintes des 
applications transportees. La caract6risation des parametres des N jeux de parametres du 
seau a jetons multi-niveau permet de nombreuses solution et peut s'adapter h peu pres & 
tous les cas de fonctionnement : 

— un cas extreme est le comportement avec N jeux de parametres independants 
agissant corame des seaux a jetons independants ; 

— un autre cas extreme est la possibility pour le niveau le plus prioritaire de 
prendre tous les jetons et d'aboutir & une rejet des paquets de tous les autres 
niveaux ; 

— entre ces deux extremes, toutes les configurations sont possibles, autorisant 
plus ou moins de rafales ou plus ou raoins de d6bit reserve par niveau. 

L'invention permet done de traiter des rafales sur les niveaux les plus 
prioritaires, du fait qu'il existe pour chaque niveau de priorite une reserve disponible 
pour prevenir toute arrivee soudaine d'un ensemble de donn6es qui ne doivent pas etre 
rejet6es. 

On rappelle qu'un seau k jeton habituel ne possede qu'un seul niveau de 
fonctionnement (il dispose d'un unique jeu de parametres) et traite done tous les paquets 
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indistinctement. En cas de congestion du reseau, les paquets sont done rejete's 
independamment de leur niveau de priorite. 

On notera que la pnSsente invention est totalement compatible avec les flux IP 
« unicast » (a destinataire unique) et « multicast » (diffuses s<51ectivement). 

On notera egalement que la presente invention permet de transmettre dans une 
meme classe de service plusieurs groupes de flux avec des priorites differentes. En 
particulier, 1'invention permet de foumir un traitement adapte a un ou un groupe de flux 
video (IPB ou hierarchique) conformement a un profil de trafic contractualis^ (SLS) par 
des valeurs caracteristiques de type seau a jeton. En effet, les parametres facilement 
mesurables et adaptables d'un seau a jetons multi-niveau (MLTB) sont un moyen 
efficace de proposer des contrats de trafic (SLA/SLS) entre operateurs reseau et 
fournisseurs de services. La presence d' informations prioritaires conduit a la 
sp6cification de ce seau. Les multiples declinaisons de ce seau sont un moyen d'offrir 
des classes de services adaptees aux exigences des clients. Quelles que soient les 
applications, le profil de trafic fait intervenir les principaux elements de caracterisatibh 
d'un flux dans un reseau : le d6bit et le ddlai. L'invention est done un moyen de defihfr 
un central avec un compromis negocie entre le debit, la taille des rafales, et le delai de 
transmission. 

Dans une premiere application avantageuse de l'invention, le trafic comprend N 
sous-flux correspondant chacun a un des N niveaux hierarchiques d'un flux hierarchique 
ou d'un agregat de flux hierarchiques. 

II s'agit par exemple d'un flux hierarchique audio/video comprenant les sous- 
flux suivants : un sous-flux audio, un sous-flux vid€o de base et un sous-flux video de 
rehaussement. 

Dans une deuxieme application avantageuse de l'invention, le trafic comprend N 
sous-flux correspondant chacun a un des N types d'images d'un flux multimedia ou d'un 
agregat de flux multimedia. 

II s'agit par exemple d'un flux video MPEG comprenant trois sous-flux 
correspondant aux trois types d'images I, P et B. 

Dans une troisieme application avantageuse de l'invention, le trafic comprend N 
flux correspondant chacun a un des flux d'un multiplex d'au moins deux flux. 
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II s'agit par exemple d'un flux video/audio multiplexe avec un flux TCP, sur un 
acces ADSL. 

Avantageusement, le trafic comprend N flux et/ou sous-flux appartenant a une 

meme classe de service. 

Ainsi, Pinvention, grace au seau & jetons multi-niveau, permet de transmettre 
dans une meme classe de service plusieurs flux et/ou sous-flux avec des priorites 
differentes. On peut distinguer plusieurs classes de service, telles que par exemple la 
classe « streaming » (contenant des flux audio et video, la classe « TCP prioritaire », la 
classe « Best Effort de r6seau IP », ...) et utiliser un seau a jeton multi-niveau pour 
chaque classe. Chaque classe de service peut etre definie par marquage des paquets, par 
Padresse IP source ou destination des paquets, par le protocole utilise pour les paquets, 
etc. 

Preferentiellement, les paquets refuses sont jetes. 

Les paquets refuses sont ceux qui ne sont pas conformes au profil de trafic defini 
par les parametres des N niveaux de fonctionnement du seau a jetons multi-niveau. 

Une autre option, moins performante mais qui rentre neanmoins dans le cadre de 
la presente invention, est de transmettre les paquets refuses apres les avoir k nouveau 
marques avec un niveau de priority plus faible. Cette option pr6sente toutefois 
P inconvenient d'augmenter la probabilite de rejet de paquets dans les noeuds 
congestionnes du r£seau. 

Avantageusement, le reseau est de type IP ou equivalent. 

Selon une caracteristique avantageuse, chacun des N niveaux de fonctionnement 
du mecanisme de seau & jetons est gere par un regulateur b^, bm,), i e {1 ^ N}, avec : 
r, le d6bit nominal du regulateur ; 

bmi la taille maximale de la m6moire-tampon de jetons du regulateur ; 
' bj(t) la valeur instantanee du remplissage de la memoi re-tampon de jetons du 
r6gulateur. 

De fa$on prgferentielle, les jetons des N memoires-tampons de jetons sont 
partag6s entre les N niveaux de priority un paquet de niveau de priorite i pouvant se voir 
attribuer des jetons d'une m6moire-tampon de jetons associee a un niveau de priorite j 
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moins prioritaire Iorsque Ies jetons disponibles dans la memoire-tampon de jetons de 
niveau de priority i ne sont pas suffisants. 

De cette facon, on favorise Ies rafales des niveaux les plus prioritaires. 

Avantageusement, pour chaque niveau de priorit6 hormis le niveau de priority le 
plus prioritaire, on garantit une quantite de jetons reserves exclusiveraent aux paquets 
poss^dant ledit niveau de priorite. 

Ainsi, on garantit une ressource minimum pour chaque niveau de priorite, sans 
exclure un usage partiellement partage" des ressources (c'est-a-dire des jetons des 
differents niveaux de fonctionnement du seau a jetons multi-niveau). 

Dans un premier mode de realisation particulier de l'invention, 1'attribution de 
jetons a un paquet de niveau de priorit6 i.est effectuee selon un mode discontinu par 
paquet et consiste a attribuer : 

soit des jetons disponibles dans la memoire-tampon de jetons de niveau de 
priorit6 i ; } 

soit des jetons disponibles dans une memoire-tampon de jetons de niveau de 
priority j moins prioritaire, Iorsque les jetons disponibles dans la memoire- 
tampon de jetons de niveau de priority i ne sont pas suffisants. i. 
Ainsi, dans le mode discontinu, un paquet ne peut se servir des ressources 

(jetons) que d'un seul niveau de fonctionnement du seau a jetons multi-niveau. 

Dans un second mode de realisation particulier de l'invention, 1'attribution de 

jetons a un paquet de niveau de priorite i est effectuee selon un mode continu par bit et 

consiste a attribuer : 

des jetons disponibles dans la memoire-tampon de jetons de niveau de priorite" i ; 
et en complement des jetons disponibles dans au moins une m6moire-tampon de 
jetons de niveau de priorite j moins prioritaire, Iorsque les jetons disponibles 
dans la memoire-tampon de jetons de niveau de priorite" i ne sont pas suffisants. 
En d'autres termes, dans le mode continu, un paquet peut se servir des ressources 
(jetons) de plusieurs niveaux de fonctionnement du seau a jetons multi-niveau a la fois. 

De facon avantageuse, les paquets acceptes par le mecanisme de seau a jetons a 
N niveaux de fonctionnement sont places dans une file d'attente. Ledit procdde 
comprend en outre une etape de mise en oeuvre d'un mecanisme de seau a jetons a un 
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seul niveau de fonctionnement avec une unique memoire-tampon de jetons, de facon a 
prendre les paquets contenus dans la file d'attente et les envoyer sur le r6seau en 
executant un lissage du trafic par limitation du d6bit instantan6 a une valeur acceptable 
par le reseau. 

Le seau a jetons a un seul niveau de fonctionnement (TBTS, pour « Token 
Bucket Traffic Shaper ») permet done de limiter les debits cretes emis par I'equipement 
r6seau supportant 1'invention. II realise une temporisation des rafales quand elles 
d6passent le debit tolere dans le reseau. 

On utilise par exemple une zone memoire, dont l'entree est ger6e par le seau 
multi-niveau (controle des rafales) et dont la sortie est g6ree par le seau a un seul niveau 
(lissage de trafic). 

L'invention concerne egalement un programme d'ordinateur comprenant des 
instructions de code de programme pour l'execution des etapes du pnxtede tel que 
precite, lorsque ledit programme est execute sur un ordinateur. 

L'invention concerne aussi un dispositif de contrSle d'un trafic de paquets de 
donnees en entr6e d'un reseau, le trafic comprenant N flux et/ou sous-flux associes 
chacun a un niveau de priorite, N > 2, chacun des paquets 6tant marque avec le niveau 
de priorite associe au flux ou sous-flux auquel appartient ledit paquet, 

ledit dispositif comprenant des moyens de mise en oeuvre d'un mecanisme de 
seau a jetons a N niveaux de fonctionnement avec N memoires-tampons de jetons 
contenant chacune un nombre de jetons disponibles, les jetons de chacune des N 
memoires-tampons de jetons etant utilises pour traiter Tun des N niveaux de priorite, 
chacun des paquets etant accepte ou refus£ selon qu'il est possible ou non de lui 
attribuer des jetons en fonction des jetons disponibles au moins dans la memoire-tampon 
de jetons utilisee pour traiter le niveau de priorite dudit paquet. 

De fa?on preferentielle, ledit procedS comprend des moyens de partage des 
jetons des N memoires-tampons de jetons'entre les N niveaux de priorite, un paquet de 
niveau de priorite i pouvant se voir attribuer des jetons d'une m6moire-tampon de jetons 
associee a un niveau de priorite j moins prioritaire lorsque les jetons disponibles dans la 
memoire-tampon de jetons de niveau de priorite i ne sont pas suffisants. 
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Avantageusement, pour chaque niveau de priority hormis le niveau de priorite le 
plus prioritaire, lesdits moyens de partage comprennent des moyens de garantie d'une 
quantite de jetons reserves exclusivement aux paquets possedant ledit niveau de priorite. 

L'invention conceme encore un equipement reseau comprenant un dispositif de 
controle tel que pr6cit£, ledit equipement reseau appartenant au groupe comprenant : 

des equipements reseau situes entre un reseau d'un fournisseur d'application ou 
de service et un reseau d'un fournisseur d'un service reseau, constituant ledit 
r6seau en entree duquel est effectue le controle d'un trafic de paquets de 
donnees ; 

des routeurs compris dans des nceuds d'un reseau d'un fournisseur d'un service 
reseau, constituant ledit r6seau en entree duquel est effectue le contr61e d'un 
trafic de paquets de donndes 

D'autres caracteristiques et avantages de 1'invention apparaitront k la lectureMe 
la description suivante d'un mode de r6alisation preference! de 1'invention, donn<5 a litre 
d'exemple indicatif et non limitatif, et des dessins annexes, dans lesquels : * 
la figure 1 presente un exemple d'architecture de rdseaux dans laquelle peut etre 
mis en oeuvre le proc6d€ de contr61e de trafic selon 1'invention ; 
la figure 2 illustre un mode de realisation particulier du precede selon 
1'invention, mettant en oeuvre deux fonctions, basees sur I'utilisation 
respectivement d'un seau k jetons multi-niveau et un seau k jetons k niveau 
unique ; 

la figure 3 illustre un regulateur g6rant un niveau de fonctionnement du seau a 
jetons multi-niveau illustre sur la figure 2, ainsi que I'utilisation dans ce 
regulateur d'un parametre Kj garantissant un minimum de ressource pour le 
niveau de priorite associe k ce regulateur ; 

la figure 4 illustre un exemple d'attributiori de jetons dans le cas ou le 
fonctionnement du seau k jetons multi-niveau est decrit avec des memoires- 
tampons (buffers) independantes ; 

la figure 5 illustre un exemple d'attribution de jetons dans le cas ou le 
fonctionnement du seau a jetons multi-niveau est decrit avec des m6moires- 
tampons (buffers) correlees. 
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L/invention concerne done un procede de controle d'un trafic de paquets de 
donnees en entree d'un reseau. Le trafic est du type comprenant N flux et/ou sous-flux 
associes chacun a un niveau de priorite, avec N > 2. Chacun des paquets est marque avec 
le niveau de priorite associe au flux ou sous-flux auquel il appartient. 

A titre d' exemple, 1' invention permet de transmettre en priorite les informations 
essentielles d'un flux video, ou de plusieurs flux video regroupes dans un agregat. Selon 
la nature du flux, cette distinction est par exemple possible soit par les images de type 
ffiP (voir definition ci-dessus), soit par les n couches d'un flux hierarchique. Si dans le 
premier cas le debit moyen des images I reste faible devant le d6bit global, dans le 
second cas reformation la plus importante et h prot6ger au maximum est definie par la 
fraction du debit global occupe par la couche de base, et pouvant representer jusqu'& 
50% du flux. En general, la couche de base est la seule a contenir les informations de 
references contenues dans les images I. 

Dans un agr6gat, toutes les donnees de meme niveau de priorite subissent le 
meme traitement. Par exemple, tous les flux de base ou toutes les images I sont traites 
comme un seul flux de debit plus important qu'une video seule. 

On presente maintenant, en relation avec la figure 1, un exemple d' architecture 
de reseaux dans laquelle peut etre mis en oeuvre le proc6d6 de controle de trafic selon 
Tinvention. 

Dans cet exemple, on considere le cas de foumisseurs de service (ISP, pour 
« Internet Service provider ») offrant un service de transmission de vid6o en mode 
continu (« streaming »). 

L' exemple d' architecture (simpliftee) illustree sur la figure 1 comprend : 

- un reseau IP de type « DiffServ » 1, g€r6 par un op6rateur reseau (aussi 
appele fournisseur du service reseau, ou NSP (pour « Network service 
Provider »)) et comprenant une pluralite de routeurs 2, & 2 5 compris dans des 
nceuds du reseau IP ; 

- deux reseaux de foumisseurs de service « streaming » 3 et 4, Tun comprenant 
deux serveurs 5 et 6, et T autre un serveur 7. Chaque r6seau de foumisseurs de 
service 3, 4 comprend en outre un equipement d'extremite 8, 9 connecte a 
Tun des routeurs du reseau IP, appe!6 routeur d'extr6mite (« edge routeur ») 
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2,, qui est charge d'envoyer les donnees d'un serveur vers une artere 
principale d'un coeur de reseau IP ; 

- deux terminaux clients 10 et 11, chacun connecte au rdseau IP 1 par exemple 
via un lien ADSL 12, 13. 

On suppose qu'il existe deux contrats de trafic (symbolises par les fleches 
ref£rencees SLA1 et SLA2 respectivement sur la figure 1) : Tun entre Poperateur du 
r6seau IP 1 et le fournisseur de service dont le reseau est reference 3, et P autre entre 
Pop6rateur du reseau IP 1 et le fournisseur de service dont le reseau est reference 4. 

Le precede selon Pinvention est mis en oeuvre dans un equipement reseau 
formant un conditionneur de trafic pour Pentose dans le reseau BP 1. Cet equipement 
reseau peut etre situe entre le reseau du fournisseur du service 3, 4 et le reseau IP 1 : 

- soit dans Tun des equipements d'extremite 8, 9 des reseaux de fournisseurs 
de service 3 et 4 ; r 

- soit dans le routeur d'extremite 2, du reseau IP 1 . 

L'equipement reseau implementant le procede selon Pinvention peut egalerflent 
etre tout routeur place au niveau d'un point de congestion dans le reseau (en particulier 
pour tout acces a un lien ADSL). 

On pr6sente maintenant, en relation avec la figure 2, un mode de realisation 
particulier du precede selon Pinvention. II permet de prot6ger les informations 
importantes des rafales et apporter des solutions h Pantinomie entre P optimisation d'un 
flux video contenant des rafales et le lissage des rafales pour un transport de qualite dans 
le reseau. 

Dans ce mode de realisation particulier du procede selon Pinvention, le 
mecanisme d'ensemble forme un « conditionneur de trafic decentralise multi-couche » 
appeie «MLDTC » (pour « Multi-Layers Decentralized Traffic Conditioner »). II est 
constitue de deux fonctions executees s6quentiellement : 

- la premiere est appelee « MLTR » (pour « Multi-Layers Traffic Regulator ») 
du fait qu'elle forme un « regulateur de trafic multi-couche ». Elle assure le 
controle de rafales par niveau hierarchique. Elle est basee sur la mise en 
ceuvre d'un seau & jetons h N niveaux de fonctionnement (reference 30), avec 
N buffers (memoires-tampons) de jetons virtuels. Chaque buffer de jetons 
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correspond k un niveau hierarchique. Chaque niveau de fonctionnement est 
defini par un jeu de parametres (voir discussion detailtee ci-apres). La 
fonction MLTR assure V attribution de jetons en fonction de la priorite du 
paquet entrant et de la ressource disponible dans le buffer de jetons 
correspondant. Dans l'exemple de la figure 2, on a N = 3 et la representation 
de trois seaux indique uniquement la distinction des trois jeux de parametres 
(il n'y a en realite qu'un seul seau a trois niveaux de fonctionnement) ; 
- la seconde est appelee « TBTS » (pour « Token Bucket Traffic Shaper ») du 
fait qu'elle est basee sur un algorithme de type seau a jetons a niveau unique 
(« Token Bucket ») (reference 31) et execute un lissage du trafic pour un 
ecoulement rSgulier sur le reseau en limitant le debit instantane a une valeur 
acceptable par le reseau. La memoire tampon de la fonction TBTS est de 
capacit6 raisonnable pour garantir un cout moindre des systemes et un temps 
de transfert limits dans la fourniture de F information a I'usager. La 
contrepartie de la taille finie est la limitation des rafales acceptees en entree 
du reseau. 

La fonction MLTR est adapt^e k T acceptation differentiae des rafales en fonction 
du niveau de priority Elle s'applique aux paquets IP (references 20 a 26 sur la figure 2) 
dont le champ DSCP ^Differentiated Services Code point ») est marqu6 soit par la 
source, soit par un systeme de classification. Chaque niveau de priority i dispose de ses 
propres parametres, pour un tampon unique, commun aux 3 niveaux, mais avec des 
niveaux d'acceptation des paquets de donn6es variables. Ce m6canisme repond aux 
attentes d'un signal video, car il ne traite pas uniformement toutes les informations. En 
effet, on rappelle qu'un codage MPEG aboutit k plusieurs niveaux d'informations qu'il 
convient de traiter diff€remment selon leur importance. L'objectif est de favoriser les 
rafales d'un niveau i par rapport & un niveau j, dont les informations sont moins 
importantes (j > i). Les paquets relatifs au niveau i ont alors la priorite pour exploiter les 
ressources disponibles. 

GrSce a la fonction TBTS, le meme d6bit moyen est obtenu pour des tailles de 
rafales diffgrentes, et tenant compte de l'intervalle les separant. Un tel mecanisme est 
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bien adapte aux rafales des flux vid6o, qui sont variables, en raison de la grande 
diversite des contenus transported (sports, actualites, paysages, ...). 

On presente maintenant de facon detaillee un exemple de realisation de la 
fonction MLTR, qui assure la regulation et le contr61e de rafales. Dans la suite de la 
description, on etudie a titre d'exemple le cas ou cette fonction MLTR est basee sur un 
seau a jetons a trois niveaux de fonctionnement (N = 3). 

Comme illustre sur la figure 3, chaque niveau de fonctionnement i du seau a 
jetons a trois niveaux de fonctionnement 30 est gere par un regulateur b,^, b mj ), i e {1, 
2, 3}, avec : 

- r; le debit nominal de ce regulateur ; 

- bmj la taille maximale du buffer de jetons de ce regulateur ; 

- bi(t) la valeur instantanee du remplissage du buffer de jetons de ce regulateur. 
La taille du buffer de jetons (bj) impose une taille maximale pour les rafales pour 

chaque niveau. La tolerance d'un regulateur de niveau i vis-a-vis des rafales de graride 
taille d6pend de la taille du buffer de jetons b ; et du debit r,. 

Les paquets conformes (c*est-a-dire ceux a qui il a pu etre attribue des jetons par 
le seau multi-niveau 30) sont places dans un buffer de paquets a emettre 28, qui forme 
un moyen de gestion d'une file d'attente. Si un nombre insuffisant de jetons est 
disponible dans le seau multi-niveau, les paquets sont alors considers comme non- 
conformes et sont elimines. lis sont jetes dans la poubelle referencee 27. Une autre 
option est de transmettre ces paquets avec une priorite plus faible. Cependant, le 
nouveau marquage des paquets pour leur attribuer une priorite plus faible augmente la 
probabib'te de rejet de paquets dans les nceuds congestionnes. 

Pour favoriser les rafales des niveaux les plus priorities, les trois buffers de 
jetons, bl, b2 et b3 sont partages entre les diff6rents niveaux. En d'autres termes, un 
paquet de niveau de priorite i peut se voir attribuer des jetons d'un buffer de jetons 
associe a un niveau de priorite j moins prioritaire 0 > i) lorsque les jetons disponibles 
dans le buffer de jetons de niveau de priorite i ne sont pas suffisants. 

Cependant, a cause de ce principe d'emprunt, les paquets de niveau i risquent 
d'utiliser toutes les ressources en jetons des niveaux moins priorities j. Ceci peut 
empScher de garantir le debit nominal au niveau j au profit du niveau i. Comme illustre 
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sur la figure 3, la solution est de limiter cet emprunt par un parametre K p propre au 
niveau j, et dont l'objectif est de proteger ce dernier des niveaux plus prioritaires en 
garantissant une quantite de ressources (jetons) reservees excliisivement aux paquets de 
niveau j. Par cons6quent, le parametre Kj garantit un seuil de remplissage des buffers de 
5 jetons au-dessous duquel les paquets d'un niveau plus prioritaire ne peuvent plus se 

servir. Le parametre Kj du regulateur de niveau j est illustre sur la figure 3. 

La valeur de Kj doit etre choisie telle que bmj > Kj > MTU. 

Ceci revient k garantir pour les paquets de niveau j le debit nominal et des rafales 
limitees par Kj. Le cas particulier oii Kjest adapte a la taille utile d'un paquet sur le 
10 reseau (MTU (« Maximum Transfer Unit », c'est-a-dire « taille maximale d'une unite 

elementaire de transfert ») pour un nSseau IP) correspond a une garantie du debit 
nominal rj pour le niveau j mais sans garantie de rafales. Les ressources en jetons 
pourraient etre utilisees par les niveaux plus prioritaires. 

Les trois jeux de param&tres definissant les trois niveaux de fonctionnement du 
15 seau a jetons multi -niveau peuvent etre decrits : 

- soit par une representation de trois buffers ind6pendants, avec un usage 
partage des ressources entre les trois niveaux ; 

- soit par une representation cumulee des ressources faisant mieux ressortir les 
priorites entre les niveaux et les interdependances de fonctionnement 

20 provenant du partage des ressources. 

Toutefois, ces representations sont identiques dans leur fonctionnement. 
On presente maintenant, en relation avec la figure 4, une description du 
fonctionnement du seau & jetons multi-niveau avec des buffers (m^moires-tampons) 
independants. 

25 Le rechargement des buffers de jetons est calcule pour chacun des trois niveaux 

au moment de Tarrivee d'un nouveau paquet, en fonction du temps le s^parant du paquet 
precedent. 

b x (/ +r)= min [(6, (/)+ r } T) bm x ] 
4 b 2 (t + T)^xmn^b 2 (t)^r 2 T}bm 2 ] (Equation 1) 

b 3 ({ + T)= min[(& 3 r v T\bm^ 
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La prise en compte du paquet arrivant de niveau i et de taille P; est obtenue par 
Talgorithme suivant : (mode paquets) 

'si(P t < 6, )=> b x = b x - P x ; envoi; 

i(P > mtre 1 Si ^ " ^ 2 "~ K * ^ b *= b *~ P i ; envoi > 
}/ autre :sifa < (b 3 - K 3 ))=* b 3 = b 3 - Renvoi; 

autre : perte; 

si(P 2 <b 2 )=*b 2 =b 2 -P 2 ;envoi; 
si(P 2 y autre : si(P 2 < (b 3 -K 3 ))=> b 3 =b 3 - P 2 ;envoi; (Equation 2) 

autre : perte; 

si(P 3 )l Si ^ 3 =& 3 -P^envoi; 

3 [autre : perte; 



La figure 4 est une representation graphique de cet algorithme d* attribution de 
jetons dans Ie cas ou le fonctionnement du seau a jetons multi-niveau est d6crit aveo.xles 
buffers independants. Elle montre Tusage possible des ressources b t , b 2 et b 3 pour 
chacun des niveaux. Les traits epais (references 41, 42 et 43) montrent le remplis?age 
des buffers de jetons (c'est-k-dire le nombre de jetons disponibles) pour chacun des 
niveaux, et les fleches les ressources (c'est-a-dire les jetons) prises par les paquets 
entrants (PI, P2 ou P3) selon leur priorite. 

On presente maintenant, en relation avec la figure 5, une description du 
fonctionnement du seau & jetons multi-niveau avec des buffers correles. 

Le fonctionnement avec trois regulateurs independants b.(i i9 bm f ), i e {1, 2, 3}, 
est equivalent au fonctionnement avec trois regulateurs dependants B^.BMf) avec : 

~ B i( f ) la valeur instantanee du remplissage du buffer de jetons virtuel relatif 
aux paquets de niveau i ; 

- BM { la taille maximale du buffer de jetons virtuel relatif aux paquets de 
niveau i. 

Les tailles de buffers de jetons par niveau sont obtenus par : 
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B 3 =* 3 

B 2 =b 2 +b 3 (Equation 3) 

5, = b l +b 2 +b 3 

Ce mode implique que : 51 > 52 > 53 

Le rechargement des buffers de jetons peut alors s'exprimer sous une forme 
equivalente a Equation 1 par : 
■3(r + 7-)=imn&<jr)+^ 

B 2 (t + T)= min[(b 2 (t)+ r 2 T> bm 2 ]+ min[(6 3 (t)+ r 3 T) 6m 3 ] 
5 3 + r)= min[(6 3 (r)+ r 3 J 1 )^ ] 

(Equation 4) 

Si on suppose que mini&dfVr, T^mJ-d,^ r, J , (Equation 4) devient : 

5, (/ + r)= 6, (0+ * 2 (0+ *3 (0+ (r. + *2 + * )^ 
5 2 (r + r)= 6 2 (0+ * 3 (0+ 0-2 + r, )r 

5 3 (f+r)=i 3 (0+r 3 T 

La figure 5 est une representation graphique de l'algorithme d' attribution de 
jetons dans le cas ou le fonctionnement du seau a jetons multi-niveau est decrit avec des 
buffers correles. Elle montre l'usage possible des ressources B„ B 2 et B 3 pour chacun 
des niveaux. De meme que sur la figure 4, les traits epais (references 51, 52 et 53) 
montrent le remplissage des buffers de jetons (c'est-a-dire le nombre de jetons 
disponibles) pour chacun des niveaux, et les fleches les ressources (c'est-a-dire les 
jetons) prises par les paquets entrants (PI, P2 ou P3) selon leur priorite. 

Si les equations du rechargement traduisent exactement le meme comportement 
pour les deux approches, le choix de 1' attribution des jetons aux paquets a rarrivee peut 
se realiser par deux alternatives : 

- en mode discontinu (paquets): un paquet ne peut se servir que d'un seul 

regulateur ; 

- en mode continu (bits): un paquet peut se servir de plusieurs r6gulateurs a la 
fois. 
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Selon le fonctionnement en mode discontinu (paquets), la prise en compte de 
1'arrivee du paquet est obtenue par ralgorithme suivant : 



sift) 



si(P 2 ) 



si(P x <B t -B 2 )=^B l =B l - P x ;envoi; 

autre:si(P x < {{B 2 -B 3 )-K 2 ))=* If 2 = f 2 'Renvoi; 

\B 3 =B 3 -P t 
autre : si{P x < (B 3 - K 3 ))=* B 2 =B 2 - P x ;envoi; 

B X =B X -P X 

autre : perte; 

si(P 2 <B 2 - B 3 ) => If 2 = f 2 'pernor, 

B 3 =B 3 -P 2 . 
B 2 = B 2 -P 2 ;envoi; 
[B X =B X -P 2 



autre : si(P 2 < (B 3 - K 3 ))= 
autre : perte; 



si(P 3 ) 



si(P 3 <B 3 )=> 
autre : perte; 



B 3 =B 3 -P 3 

B 2 =B 2 -P 3 ;envoi; 

B X =B X -P 3 



(Equation 5) 
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II est k noter que (Equation 2) et (Equation 5) sont equivalentes. 

Dans ce mode de fonctionnement discontinu (paquets), un paquet est servi par 
les ressources du niveau correspondant au paquet (niveau i) ou d'un niveau moins 
prioritaire (niveau j). II est h noter que ce fonctionnement n'est pas optima], car un 
paquet entrant est rejet6 merae si la somme des ressources disponibles r6parties sur les 3 
niveaux est suffisante. 

Selon le fonctionnement en mode continu (bits), la prise en compte de Tamvee 
du paquet est obtenue par ralgorithme suivant : 
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*(/>) 



sifa =6, -P; envoi; 

autre :si(iP l -b,)<(p 2 -K 2 ))= 



b 2 =b 2 -(P x -b x \ 



si(P 2 ) 



si(P 3 ) 



b.=0 

autre : sifa - fa + (b 2 - K 2 )))< (b, - K 3 ))=> • 
autre : perte; 

si(P 2 < b 2 )=> b 2 =b 2 - P 2 ;envoi; 

autre :si(P 2 < (b 3 -K 3 ))=> j* 3 ~ * 3 ^lenvoi; 

autre : perte; 

si(P z < b 3 )=» b 2 =b 3 - P 3 \envoi\ 
autre : perte; 



renvoi; 

b^b,-(P,-(bi+(b 2 -K 2 ))) 
b 2 = K 2 ;enwi; 
b,=0 



A priori ce mode de fonctionnement continu (bits) est plus optimal que le mode 
discontinu (paquets). En effet, il permet une utilisation maximale de ressources propres 
du niveau avant de demander des ressources a un niveau moins prioritaire. 

On presente maintenant de fagon detaillSe un exemple de realisation de !a 
fonction TBTS qui assure la mise en forme du trafic. 

Le seau & jetons k niveau unique 31, sur lequel est bas6 cette fonction TBTS, est 
par exemple defini par les parametres suivants : 

- R, le debit moyen ; 

- R max , le debit maximal a la sortie ; 

- B(t), la valeur instantanee du remplissage du buffer de jetons (B^ est la 
taille maximale du buffer de jetons) ; 

- S, la valeur instantanee du remplissage du buffer de paquets 28 (S max est la 
taille maximale du buffer de paquets 28) ; 
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- T, le temps separant Tarrivee de deux paquets consecutifs ; 

- x y la duree d'une rafale de paquets. 

Les paquets conformes (c'est-^-dire ceux a qui il a pu etre attribue des jetons par 
le seau k niveau unique 31) sont transmis alors que les paquets non-conformes sont 
retardes dans le buffer de paquets 28 pour les contenir dans Tenveloppe de trafic cible. 
La taille du buffer de paquets 28 est k manipuler avec precaution car elle peut induire un 
delai supplemental, qui doit rester raisonnable. 

Le fonctionnement du seau a niveau unique 31 (et done de la fonction TBTS) 
peut Stre decrit par les equations suivantes : 



i? max .T<5 raax +/?.r=>T<. 



La prise en compte du paquet P, est obtenue par Talgorithme suivant 



si 



j/(P, < B)=> B = B-P t \envoi\ 
autre : bufferisation; 

Si on considSre r max , le d6bit maximal k la sortie de la fonction MLTR, 
revolution du remplissage du buffer de paquets 28 entre Farrivee de deux paquets 
consecutifs peut etre ddcrit par Tequation suivante : 

S(t + T)<S(t)-B mwi +(r max -R)T 

et S (t)-RT-B mm <S(t + T)<S(t)+(r max -R)T 
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REVENDICATIONS 

1. Procede de controle d'un trafic de paquets de donn6es en entree d'un reseau, le 
trafic comprenant N flux et/ou sous-flux associes chacun & un niveau de priority N > 2, 
chacun des paquets etant marque avec le niveau de priorite associe au flux ou sous-flux 
auquel appartient ledit paquet, 

caracterise en ce qu'il comprend une etape de mise en ceuvre d'un m6canisme de seau a 
jetons a N niveaux de fonctionnement avec N memoires-tarnpons de jetons contenant 
chacune un nombre de jetons disponibles, les jetons de chacune des N memoires- 
tarnpons de jetons etant utilises pour traiter Tun des N niveaux de priorite, chacun des 
paquets etant accept^ ou refuse selon qu'il est possible ou non de lui attribuer des jetons 
en fonction des jetons disponibles au moins dans la memoi re-tampon de jetons utilisee 
pour traiter le niveau de priority dudit paquet. 

2. Procede selon la revendication 1, caracterise en ce que le trafic comprend N 
sous-flux coirespondant chacun a un des N niveaux hterarchiques d'un flux hierarchique 
ou d'un agr^gat de flux hi6rarchiques. 

3. Procede selon la revendication 1, caracterise en ce que le trafic comprend N 
sous-flux correspondant chacun a un des N types d'images d'un flux multimedia ou d'un 
agregat de flux multimedia. 

4. Procede selon la revendication 1, caracterise en ce que le trafic comprend N flux 
correspondant chacun & un des flux d'un multiplex d'au moins deux flux. 

5. Procede selon l'une quelconque des revendications 1 a 4, caracterise en ce que le 
trafic comprend N flux et/ou sous-flux appartenant k une meme classe de service. 

6. Procede selon l'une quelconque des revendications 1 a 5, caracterise en ce que 
les paquets refuses sont jetes. 

7. Procede selon l'une quelconque des revendications 1 a 6, caracterise en ce que le 
reseau est de type IP ou equivalent. 

8. Precede selon l'une quelconque des revendications 1 a 7, caracterise en ce que 
chacun des N niveaux de fonctionnement du mecanisme de seau £ jetons est ger6 par un 
regulateur bi(r 3 , bmj), ie {la N}, avec : 

r s le d6bit nominal du regulateur ; 

bmj la taille maximale de la memoire-tampon de jetons du regulateur ; 
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bj(t) la valeur instantanee du remplissage de la memoire-tampon de jetons du 
regulateur. 

9. Precede selon Tune quelconque des revendications 1 & 8, caracterise en ce que 
les jetons des N memoi res-tampons de jetons sont partag6s entre les N niveaux de 
priority un paquet de niveau de priorite i pouvant se voir attribuer des jetons d'une 
memoire-tampon de jetons associee & un niveau de priorite j moins prioritaire lorsque les 
jetons disponibles dans la memoire-tampon de jetons de niveau de priorite i ne sont pas 
suffisants, 

10. Precede selon la revendication 9, caracterise en ce que, pour chaque niveau de 
priorit6 hormis le niveau de priorite le plus prioritaire, on garantit une quantity de jetons 
(Kj) reserves exclusivement aux paquets possedant ledit niveau de priorite. 

11. Precede selon Tune quelconque des revendications 9 et 10, caracterise en ce que 
1'attribution de jetons a un paqiiet de niveau de priorite i est effectuee selon un mode 
discontinu par paquet et consiste a attribuer : 

soit des jetons disponibles dans la memoire-tampon de jetons de niveau de 
priorite i ; 

soit des jetons disponibles dans une memoire-tampon de jetons de niveau de 
priority j moins prioritaire, lorsque les jetons disponibles dans la memoire- 
tampon de jetons de niveau de priorite i ne sont pas suffisants. 

12. Precede selon Tune quelconque des revendications 9 et 10, caracterise en ce que 
1'attribution de jetons & un paquet de niveau de priorite i est effectuee selon un mode 
continu par bit et consiste h attribuer : 

des jetons disponibles dans la memoire-tampon de jetons de niveau de priorite i ; 
et en complement des jetons disponibles dans au moins une memoire-tampon de 
jetons de niveau de priorite j moins prioritaire, lorsque les jetons disponibles 
dans la memoire-tampon de jetons de niveau de priorite i ne sont pas suffisants. 

13. Precede selon Tune quelconque des revendications 1 a 12, caracterise en ce que 
les paquets acceptes par le mecanisme de seau a jetons a N niveaux de fonctionnement 
sont places dans une file d'attente, 

et en ce que ledit precede comprend en outre une etape de mise en ceuvre d'un 
mecanisme de seau & jetons & un seul niveau de fonctionnement avec une unique 
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memoire-tampon de jetons, de fa9on & prendre les paquets contenus dans la file d'attente 
et les envoyer sur le reseau en ex6cutant un lissage du trafic par limitation du debit 
instantane h. une valeur acceptable par le reseau. 

14. Programme d'ordinateur, caracterise en ce qu'il comprend des instructions de 
5 code de programme pour Texecution des etapes du procede selon Tune quelconque des 

revendications 1 a 3, lorsque ledit programme est execute sur un ordinateur. 

15. Dispositif de contr61e d'un trafic de paquets de donn6es en entr£e d'un reseau, le 
trafic comprenant N flux et/ou sous-flux associes chacun a un niveau de priorite, N > 2, 
chacun des paquets etant marqu6 avec le niveau de priorite associe au flux ou sous-flux 

10 auquel appartient ledit paquet, 

caracterise en ce qu'il comprend des moyens de mise en ceuvre d'un mScanisme de seau 
a jetons & N niveaux de fonctionnement avec N memoires-tampons de jetons contenant 
chacune un nombre de jetons disponibles, les jetons de chacune des N memoires- 
tampons de jetons etant utilises pour traiter Tun des N niveaux de priorite, chacun des 

15 paquets Stant accept^ ou refuse selon qu'il est possible ou non de lui attribuer des jetons 

en fonction des jetons disponibles au moins dans la memoire-tampon de jetons utilis6e 
pour traiter le niveau de priorite dudit paquet. 

16. Dispositif selon la revendication 15, caracteris6 en ce qu'il comprend des 
moyens de partage des jetons des N memoires-tampons de jetons entre les N niveaux de 

20 priorite, un paquet de niveau de priorite i pouvant se voir attribuer des jetons d'une 

memoire-tampon de jetons associ^e a un niveau de priorite j moins prioritaire lorsque les 
jetons disponibles dans la memoire-tampon de jetons de niveau de priority i ne sont pas 
suffisants. 

17. Dispositif selon la revendication 16, caracterise en ce que, pour chaque niveau de 
25 priority hormis le niveau de priorite le plus prioritaire, lesdits moyens de partage 

comprennent des moyens de garantie d'une quantite de jetons (Kj) reserves 
exclusivement aux paquets possedant ledit niveau de priorite. 

18. Equipement reseau comprenant un dispositif de controle selon Tune quelconque 
des revendications 15 & 17, caracterise en ce que ledit equipement r6seau appartient au 

30 groupe comprenant : 
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des equipements reseau situes entre un reseau d'un fournisseur d' application ou 
de service et un reseau d'un fournisseur d'un service reseau, constituant ledit 
reseau en entree duquel est effectue le contr61e d'un trafic de paquets de 
donnees ; 

des routeurs compris dans des noeuds d'un reseau d'un fournisseur d'un service 
reseau, constituant ledit reseau en entree duquel est effectud le controle d'un 
trafic de paquets de donnees. 
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